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Display choices: 

> technology type: LCD, OLED,... 

> price: >$$, <$$, $$<>$$ 

> size (dimensions: WxHxD) 

> parameters: black & white, color, 
resolution, gray-scale, intensity, 
contrast, brightness, refresh rate... 
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hor each choice of display 

(characterized by a 
combination of the display 
choices): 
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Energy Model (Static/Dy namic): 
Average screen size 
corresponding to area of interest 
(e.g., a frame or window) 
Average values for display 
parameters 

Suggested values for display 
parameters (functionality level) 
per pixel or group of pixels 
(resolution, refresh rate, color, 
brightness...) 

Suggested screen areas not 
requiring full functionality level 
and suggested durations 
Power consumption 
characteristics (power as a 
function of number of pixels 
turned on, and/or power as a 
function of display parameter 
values) 



1 570 

(3 



Modify choice of 
display to suit 
constraints 



\ 



Fig. 5A 
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Memory: 

524 

> Operating System' 526 
Windowing Environment 



> 
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File System 
Application Software' 
Browser 532 
Device Drivers' 536 
Frame Buffer(s)^ 3Q 
Battery Monitor / 

✓522 

Energy Model Creator - 

Energy-aware software 
control s 520 
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Activate-Deactivate' 



Display 512 a 



Display Panel 



Controller 



Drivers 
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Image Proc essor 
_ 
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Profiling Parameters: 



Operating power 
Battery Capacity (current state) 
Power savings 
Cost 

User-specified Hints (user-interface) 
Application-generated Hints 
! (indications) 
Operating scenario 
Image Repertoire 
Screen Characteristics 

- Resolution, Brightness, Contrast 

- Array Size 

- Refresh Rate 

- Color and Gray-Scale Variations 
Ambient light 

Processing Requirements 
Memory Capacity 

Functionality Supported by the Display 
(display technology; display drivers) 
Number of Displays (and, IF >1 , How 
Data is Partitioned among Displays) 
Acceptable Thresholds 
Acceptable Duration of Reduced 
Functionality Levels 
Transition Overhead 
Transition Hysteresis 
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Display Parameters- 



$|* size 

♦ resolution 

♦ color 

♦ gray-scale 

♦ intensity 

♦ brightness 

♦ contrast 

♦ refresh rate 
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Energy Model (Static/Dy namic)- 



Average screen size 
corresponding to area of interest 
(e.g., a frame or window) 
Average values for display 
parameters 

Suggested values for display 
parameters (functionality level) 
per pixel or group of pixels 
(resolution, refresh rate, color, 
brightness...) 

Suggested screen areas not 
requiring full functionality level 
and suggested durations 
Power consumption 
characteristics (power as a 
function of number of pixels 
turned on, and/or power as a 
function of display parameter 
values) 



Fig. 5B 
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/ start energy-aware V- Qo2 
V goftware control design / 



identity layer ot 
software at which 
energy-aware software 
control is embodied 
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create an energy model 
(static or run-time energy 
profiling) 



identify pixel-blocks designated for 
being controlled, and for each 
such pixel-block begin: 



i 



use the energy model and 
parameters to determine 
whether there are any pixel- 
blocks to be controlled 



identify each pixel-block 
functionality (display parameter), 
and for each parameter begin: 



identify threshold values and 
round-off levels 



identify any constraints on the 
match (partly/entirly) 




match pixel-block functionality with 
attributes of hardware (one of the 
displays) 



i 



send signals to device drivers that 
control the matched display 




Fig. 6 
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for each pixel-block on the 
screen begin: 



measure level of functionality 
used by measuring values of 
display parameters 



compare the measured values of ' 
display parameters with their 
respective full values 



designate the pixel-block as a 
candidate for being controlled if 
less than the full level of 
functionality is being used 



N 



last pixel-block 
on the display? 

Y 

Q end y 



0$ 



Fig. 7A 
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► 


for each pixel-block on the 




display begin: 



determine if full functionality level is , 
required (measured by required 
values of display parameters) 
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detect hints regarding level of 
functionality (e.g., OK to brighten 
only window of focus and dim 
background) 



compare the required values of 
display parameters with their 
respective full values 



designate the pixel-block as a 
candidate for being controlled if the 

full level of functionality is not 
required 




Fig. 7B 



